Business rules help to define the structure, constraints, policies, and other aspects of a business or organization. As the size of the business grows, it becomes more important to efficiently enforce the business rules across the various services, products, personnel, and other organizational units within the business. Accordingly, many businesses rely on an integrated platform, such as service oriented architecture (SOA), system as a service (SaaS), cloud computing, or another platform that allows the business rules to be modularly integrated into applications that carry out the functions and daily operations of the business. By separating the definition of the business rules from the applications that utilize the business rules, businesses can add or modify business rules to remain agile in the face of evolving legal and regulatory requirements, labor conditions, marketplace trends, and other criteria.
To manage business rules in these platforms, the user either directly edits the code that defines the business rule, or uses a graphical rule editor, similar to an integrated development environment (IDE), that allows the business rule to be edited at the code level. However, even with the availability of browse and search functions in the rule editor, the sheer number and types of data sources, conditions, actions, and other criteria for defining a business rule may leave the user at a loss on how to actually define a new business rule or modify an existing business rule. As the business application grows in complexity and scope, the usability of the rule editor may suffer, particularly if the user is not intimately familiar with the organization of the rule dictionaries or the code level details for implementing the business rules within the integrated platform. As such, integrated platform deployments may not be leveraged to their fullest potential.
Based on the foregoing, there is a need for a method to provide facilitated business rule authoring and management.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.